Day 25｜健康檢測：如何確定設定的模型可以穩定連線？

昨天聊了 Gateway 跟 Fallback。今天要分享模型健康檢測——如何確定自己設定的模型真的可以穩定連線？

健康檢測是什麼

健康檢測分成兩層。Credential 層是輕量的連線檢查，驗證這把 API Key 能不能連上、認證過不過，不會真的去呼叫模型；Deployment 層則是送一次最小化的真實請求，驗證這個特定的 model 真的能正常回應。觸發方式有三種：手動按「檢查」按鈕、可以選擇性開啟的排程（每個 Deployment 自己決定要不要排程，預設關閉），還有新增 Deployment 的當下會自動跑一次。

為什麼一開始只做連線層級的檢查，後來覺得不夠

ping() 一開始只驗證連線、不驗證特定 model，是「先簡化再回頭補」的情況。當時的考量是：真的打一次 model 有 token 成本，而且某個 model 被停用或帳號沒權限，不該讓整條連線被判定不可用。

但這個簡化留下一個很糟糕的場景：即使 API 入口打得通，服務這邊設定錯誤（例如 model 名稱寫錯）導致模型最終回應失敗，健康檢測卻依然顯示正常——這種「明明會失敗，卻顯示健康」的落差，會讓人開始質疑健康檢測本身還可不可信。

修 bug 的過程自己又弄壞了另一個東西

發現這個問題是在實際測試時撞見的：在一個封閉網路的情況下，卻看到一個打向 OpenAI 的 model 顯示連線正常——這顯然不對，才讓我意識到 model 檢測並沒有像原本以為的那樣完整，開始回頭追查健檢的邏輯到底哪裡出了問題。

修法的第一版把 maxTokens 設成 5 想省一點成本，結果反而把正常的 model 判定成不健康。有意思的是，這個坑其實正職工作時就踩過——GPT-5 系列的參數跟其他版本不一樣，會讓健檢失效——只是在開發這個個人版的過程中，把這件事忘得一乾二淨。

這也讓我更確定一件事：單元測試沒辦法覆蓋到所有真實情境時，測試全過並不代表功能真的完成，還是得實際操作過、拿真的環境驗證一次才算數。

小結

健康檢測從一開始只驗證連線，到後來拆成連線層跟 model 層兩層，中間經過一次「發現假陽性→動手修→修法自己又壞掉→再修一次」的完整過程。已知限制不是寫下來就結束了，真正被實際情境踩到之後，才會知道當初的評估夠不夠。

明天要聊 Web UI 跟用量追蹤—整合跨廠商模型的預算與流量監控，並透過介面功能先行與真實數據對接，打造一站式的模型管控中心。